1. Field of the Invention
This invention relates generally to computer systems that implement transactional memory, and more specifically to a system and methods for communication between transactions using transaction communicator objects for which transaction isolation properties are relaxed.
2. Description of the Related Art
Transactional memory is a promising technology to ease programming of multiprocessor systems. With transactional memory, a thread can execute a block of code as a transaction, which may either commit (in which case its effects become visible to other threads) or abort (in which case its effects are discarded). A transactional memory system manages the transactions, ensuring that transactions that commit are isolated (i.e. that each transaction appears as though it were executed without any operations of other transactions being interleaved with its own) and that the transactions appear to be executed in a consistent order (i.e. the transaction order). Thus, a transaction sees the effects of those transactions that precede it in the transaction order, and no transaction sees partial effects of any other transaction.
The isolation property of transactions can greatly simplify concurrent programming. For example, a programmer can consider each transaction separately, rather than having to consider all possible interleavings of its operations with the operations of other transactions. However, isolation can also limit the applicability of transactions. For example, isolated transactions are incompatible with some common synchronization mechanisms, such as barriers and condition variables. More generally, isolation disallows programming idioms that require communication among transactions while they are active (i.e. not yet committed or aborted).
Some previous systems employ “synchronizers”, which relax isolation to allow concurrent transactions to cooperate. Synchronizers maintain “collaborator sets” that are guaranteed to commit or abort together, providing the equivalent of a bidirectional dependency between any two transactions in a collaborator set. This bidirectional dependency introduces difficulties in the use and implementation of synchronizers, because transactions in a collaborator set that is about to commit could be forced to abort by another transaction belatedly joining the collaborator set. Tracking dependencies among transactions has been proposed as a way to reduce aborts in software transactional memory. However, prior approaches to tracking dependencies maintain the isolation properties of the transactions. Therefore, transactions with cyclic dependencies must all abort if one aborts.